﻿<h1>Expression Evaluation Orders</h1>

<p>
This article will explain <a href="expressions-and-statements.html">expression</a>
evaluation orders in all kinds of scenarios.
</p>

<h3>An Expression Is Evaluated After the Expressions It Depends On</h3>

<div>
This is easy to comprehend.
An apparent example is an expression is evaluated later than its sub-expressions.
For example, in a function call <code>f(x, y[n])</code>,
<ul>
<li>
	<code>f()</code> is evaluated later than its depended expressions,
	including <code>f</code>, <code>x</code> and <code>y[n]</code>.
</li>
<li>
	the evaluation of the expression <code>y[n]</code> is later than
	the evaluations of <code>n</code> and <code>y</code>.
</li>
</ul>

<p>
Please read <a href="packages-and-imports.html#initialization-order">program resource initialization order</a>
for another example on package-level variable initialization orders.
</p>
</div>

<a class="anchor" id="package-level-variables"></a>
<h3>Initialization Order of Package-Level Variables</h3>

<div>
<p>
When a package is loaded at run time, Go runtime
will try to initialize uninitialized package-level variables
which have no dependencies on uninitialized variables,
by their declaration order.
The process might be applied (looped) several times,
until no variables are initialized in such a process.
For a successfully compiled Go program, there should be
no uninitialized variables after all such processes end.
</p>

<p>
Package-level variables appearing as blank identifers are
treated like any other variables in the initialization process.
</p>

For example, the following program should print <code>yzxw</code>.
<ol>
<li>
	In the first run of above described process, <code>y</code> and <code>z</code>
	are the only two uninitialized variables which have no dependencies on
	uninitialized variables, so they are initialized by their declaration order.
</li>
<li>
	In the second run of above described process, <code>x</code>
	is the only uninitialized variable which has no dependencies
	on uninitialized variables, so it is initialized.
</li>
<li>
	In the third run of above described process, <code>w</code>
	is the only uninitialized variable which has no dependencies
	on uninitialized variables, so it is initialized.
</li>
</ol>

<pre class="line-numbers"><code class="language-go">package main

var (
	_ = f("w", x)
	x = f("x", z)
	y = f("y")
	z = f("z")
)

func f(s string, deps ...int) int {
	print(s)
	return 0
}

func main() {
	f("\n")
}
</code></pre>

<p>
(Note, Before Go SDK 1.13, the standard Go compiler
<a href="https://github.com/golang/go/issues/22326">doesn't implement the rule correctly</a>.
If the above program is compiled with the standard Go compiler version 1.12, it will print <code>zxwy</code>.)
</p>

<!--
https://github.com/golang/go/issues/31292
https://github.com/golang/go/commit/451cf3e2cd8950571f436896a3987343f8c2d7f6
-->

<p>
Multiple variables on the left-hand side of a variable declaration
initialized by single multi-valued expression on the right-hand side
are initialized together. For example, for a package-level variable
declaration <code>var x, y = f()</code>, variables <code>x</code> and <code>y</code>
will be initialized together. In other words, no other variables will
be initialized between them.
</p>

If hidden dependencies exists between variables,
the initialization order between those variables is unspecified.
In the following example (copied from Go specification),
<ul>
<li>
	the variable <code>a</code> will be initialized after <code>b</code> for sure,
</li>
<li>
	but whether <code>x</code> is initialized before <code>b</code>, between
	<code>b</code> and <code>a</code>, or after <code>a</code>, is not specified.
</li>
<li>
	and the moment at which function <code>sideEffect()</code> is called (before
	or after <code>x</code> is initialized) is also not specified.
</li>
</ul>

<pre class="line-numbers"><code class="language-go">// x has a hidden dependency on a and b
var x = I(T{}).ab()
// Assume sideEffect is unrelated to x, a, or b.
var _ = sideEffect()
var a = b
var b = 42

type I interface    { ab() []int }
type T struct{}
func (T) ab() []int { return []int{a, b} }
</code></pre>

<p>
</p>


</div>

<h3>The Usual Order</h3>

<div>

For the evaluations within a function body, Go specification says

<div class="alert alert-success">
...,
when evaluating the operands of an expression, assignment, or return statement,
all function calls, method calls, and (channel) communication operations
are evaluated in lexical left-to-right order.
</div>

<p>
The just described order is called <b><i>the usual order</i></b>.
</p>

<p>
Please note that an explicit value conversion <code>T(v)</code> is not a function call.
</p>

For example, in an expression <code>[]int{x, fa(), fb(), y}</code>,
assume <code>x</code> and <code>y</code> are two variables,
<code>fa</code> and <code>fb</code> are two functions, then the call <code>fa()</code>
is guaranteed to be evaluated (executed) before <code>fb()</code>.
However, the following the evaluation orders are unspecified in Go specification:
<ul>
<li>
	the evaluation order of <code>x</code> (or <code>y</code>) and <code>fa()</code> (or <code>fb()</code>).
</li>
<li>
	the evaluation order of <code>x</code>, <code>y</code>, <code>fa</code> and <code>fb</code>.
</li>
</ul>

Another example, the following assignment, is demoed in Go specification.

<pre class="disable-line-numbers111"><code class="language-go">y[z.f()], ok = g(h(a, b), i()+x[j()], <-c), k()
</code></pre>

where
<ul>
<li>
	<code>c</code> is a channel expression and will be evaluated to a channel value.
</li>
<li>
	<code>g</code>, <code>h</code>, <code>i</code>, <code>j</code> and <code>k</code>
	are function expressions.
</li>
<li>
	<code>f</code> is a method of expression <code>z</code>.
</li>
</ul>

Also considering the rule mentioned in the last section, compilers should guarantee the following evaluation orders at run time.
<ul>
<li>
	The function calls, method calls and channel communication operations
	happen in the order <code>z.f()</code>→<code>h()</code>→<code>i()</code>→<code>j()</code>→<code>&lt;-c</code>→<code>g()</code>→<code>k()</code>.
</li>
<li>
	<code>h()</code> is evaluated after the evaluations of expressions <code>h</code>, <code>a</code> and <code>b</code>.
</li>
<li>
	<code>y[]</code> is evaluated after the evaluation of <code>z.f()</code>.
</li>
<li>
	<code>z.f()</code> is evaluated after the evaluation of expression <code>z</code>.
</li>
<li>
	<code>x[]</code> is evaluated after the evaluation of <code>j()</code>.
</li>
</ul>

However, the following orders (and more others) are not specified.
<ul>
<li>
	The evaluation order of <code>y</code>, <code>z</code>, <code>g</code>,
	<code>h</code>, <code>a</code>, <code>b</code>, <code>x</code>,
	<code>i</code>, <code>j</code>, <code>c</code> and <code>k</code>.
</li>
<li>
	The evaluation order of <code>y[]</code>, <code>x[]</code> and <code>&lt;-c</code>.
</li>
</ul>

By the usual order, we know the following declared variables <code>x</code>,
<code>m</code> and <code>n</code> (also demoed in Go specification)
will be initialized with ambiguous values.

<pre class="line-numbers"><code class="language-go">	a := 1
	f := func() int { a++; return a }

	// x may be [1, 2] or [2, 2]: evaluation order
	// between a and f() is not specified.
	x := []int{a, f()}

	// m may be {2: 1} or {2: 2}: evaluation order
	// between the two map element assignments is
	// not specified.
	m := map[int]int{a: 1, a: 2}

	// n may be {2: 3} or {3: 3}: evaluation order
	// between the key and the value is unspecified.
	n := map[int]int{a: f()}
</code></pre>

<p>
</p>

</div>

<a class="anchor" id="value-assignment"></a>
<h3>Evaluation and Assignment Orders in Assignment Statements</h3>

<div>

Beside the above introduced rules, Go specification specifies more on the expression evaluation order
the order of individual assignments in an assignment statement:

<div class="alert alert-success">
The assignment proceeds in two phases.
First, the operands of index expressions and pointer indirection
(including implicit pointer indirection in selectors) on the left
and the expressions on the right are all evaluated in the usual order.
Second, the assignments are carried out in left-to-right order.
</div>

<p>
Later, we may call the first phase as evaluation phase and the second phase as carry-out phase.
</p>

<p>
Go specification doesn't specify clearly whether or not the assignments carried-out
during the second phase may affect the expression evaluation results got in the first phase,
which ever caused
<a href="https://github.com/golang/go/issues/23188#issuecomment-403951267">some</a>
<a href="https://github.com/golang/go/issues/15620">disputes</a>.
So, here, this article will explain more on the evaluation orders in value assignments.
</p>

<p>
Firstly, let's clarify that the assignments carried-out during the second phase
don't affect the expression evaluation results got at the end of the first phase.
</p>

<p>
To make the following explanations convenient, we assume that
the container (slice or map) value of an index destination expression in an assignment is always addressable.
If it is not, we can think the container value has already been saved in and
replaced by a temporary addressable container value before carrying out the second phase.
</p>

At the time of the end of the evaluation phase and just before the carry-out phase starts,
each destination expression on the left of an assignment
has been evaluated as its elementary form.
Different destination expressions have different elementary forms.
<ul>
<li>
	If a destination expression is a blank identifier, then its elementary form is still a blank identifier.
</li>
<li>
	If a destination expression is a container (array, slice or map) index expression <code>c[k]</code>,
	then its elementary form is <code>(*cAddr)[k]</code>,
	where <code>cAddr</code> is a pointer pointing to <code>c</code>.
</li>
<li>
	For other cases, the destination expression must result an addressable value,
	then its elementary form is a dereference to the address of the destination expression evaluation result.
</li>
</ul>

Assume <code>a</code> and <code>b</code> are two addressable variables of the same type, the following assignment

<pre class="line-numbers"><code class="language-go">	a, b = b, a
</code></pre>

will be executed like the following steps:

<pre class="line-numbers"><code class="language-go">// The evaluation phase:
P0 := &a; P1 := &b
R0 := b; R1 := a 

// The elementary form: *P0, *P1 = R0, R1

// The carry-out phase:
*P0 = R0
*P1 = R1
</code></pre>

<p>
</p>

Here is another example, in which <code>x[0]</code> instead of <code>x[1]</code> is modified.

<pre class="line-numbers must-line-numbers"><code class="language-go">	x := []int{0, 0}
	i := 0
	i, x[i] = 1, 2
	fmt.Println(x) // [2 0]
</code></pre>

The decomposed execution steps for the line <i>3</i> shown below are like:

<pre class="line-numbers"><code class="language-go">// The evaluation phase:
P0 := &i; P1 := &x; T2 := i
R0 := 1; R1 := 2
// Now, T2 == 0

// The elementary form: *P0, (*P1)[T2] = R0, R1

// The carry-out phase:
*P0 = R0
(*P1)[T2] = R1
</code></pre>

<p>
</p>

An example which is a little more complex.

<pre class="line-numbers must-line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	m := map[string]int{"Go": 0}
	s := []int{1, 1, 1}; olds := s
	n := 2
	p := &n
	s, m["Go"], *p, s[n] = []int{2, 2, 2}, s[1], m["Go"], 5
	fmt.Println(m, s, n) // map[Go:1] [2 2 2] 0
	fmt.Println(olds)    // [1 1 5]
}
</code></pre>

<p>
</p>

The decomposed execution steps for the line <i>10</i> shown below are like:

<pre class="line-numbers"><code class="language-go">// The evaluation phase:
P0 := &s; PM1 := &m; K1 := "Go"; P2 := p; PS3 := &s; T3 := 2
R0 := []int{2, 2, 2}; R1 := s[1]; R2 := m["Go"]; R3 := 5
// now, R1 == 1, R2 == 0

// The elementary form:
//     *P0, (*PM1)[K1], *P2, (*PS3)[T3] = R0, R1, R2, R3

// The carry-out phase:
*P0 = R0
(*PM1)[K1] = R1
*P2 = R2
(*PS3)[T3] = R3
</code></pre>

<p>
</p>

The following example rotates all elements in a slice for one index.

<pre class="line-numbers"><code class="language-go">	x := []int{2, 3, 5, 7, 11}
	t := x[0]
	var i int
	for i, x[i] = range x {}
	x[i] = t
	fmt.Println(x) // [3 5 7 11 2]
</code></pre>

<p>
</p>

Another example:

<pre class="line-numbers"><code class="language-go">	x := []int{123}
	x, x[0] = nil, 456        // will not panic
	x, x[0] = []int{123}, 789 // will panic
</code></pre>

<p>
</p>

<p>
Although it is legal, it is not recommended to use complex multi-value assignments in Go,
for their readabilities are not good and they have negative effects on both compilation speed and execution performance.
</p>

As mentioned above,
not all orders are specified in Go specification for value assignments,
so some bad written code may produce different results.
In the following example, the expression order of
<code>x+1</code> and <code>f(&amp;x)</code> is not specified.
So the example may print <code>100 99</code> or <code>1 99</code>.

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	f := func (p *int) int {
		*p = 99
		return *p
	}

	x := 0
	y, z := x+1, f(&x)
	fmt.Println(y, z)
}
</code></pre>

<p>
</p>

The following is another example which will print ambiguous results.
It may print <code>1 7 2</code>, <code>1 8 2</code> or <code>1 9 2</code>,
depending on different compiler implementations.

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	x, y := 0, 7
	f := func() int {
		x++
		y++
		return x
	}
	fmt.Println(f(), y, f())
}
</code></pre>

<p>
</p>

</div>

<h3>Expression Evaluation Orders in <code>switch-case</code> Code Blocks</h3>

<div>

The expression evaluation order in a <code>switch-case</code> code block has been
<a href="control-flows.html#switch-case">described before</a>.
Here just shows an example.
Simply speaking, before a branch code block is entered, the <code>case</code> expressions
will be evaluated and compared with the switch expression one by one,
until a comparison results <code>true</code>.

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	f := func(n int) int {
		fmt.Printf("f(%v) is called.\n", n)
		return n
	}

	switch x := f(3); x + f(4) {
	default:
	case f(5):
	case f(6), f(7), f(8):
	case f(9), f(10):
	}
}
</code></pre>

<p>
At run time, the <code>f()</code> calls will be evaluated by the order
from top to bottom and from left to right,
until a comparison results <code>true</code>.
So <code>f(8)</code>, <code>f(9)</code> and <code>f(10)</code>
will be not evaluated in this example.
</p>

The output:
<pre class="output"><code>f(3) is called.
f(4) is called.
f(5) is called.
f(6) is called.
f(7) is called.
</code></pre>

<p>
</p>

</div>

<h3>Expression Evaluation Orders in <code>select-case</code> Code Blocks</h3>

<div>

<p>
When executing a <code>select-case</code> code block, before entering a branch code block,
all the channel operands of receive operations and the operands of send statements
involved in the <code>select-case</code> code block are evaluated exactly once,
in source order (from top to bottom, from left to right).
</p>

<p>
Note, the target expression being assigned to by a receive <code>case</code>
operation will only be evaluated if that receive operation is selected later.
</p>

In the following example, the expression <code>*fptr("aaa")</code> will never get evaluated,
for its corresponding receive operation <code>&lt;-fchan("bbb", nil)</code> will not be selected.

<pre class="line-numbers"><code class="language-go">package main

import "fmt"

func main() {
	c := make(chan int, 1)
	c <- 0
	fchan := func(info string, c chan int) chan int {
		fmt.Println(info)
		return c
	}
	fptr := func(info string) *int {
		fmt.Println(info)
		return new(int)
	}

	select {
	case *fptr("aaa") = <-fchan("bbb", nil): // blocking
	case *fptr("ccc") = <-fchan("ddd", c):   // non-blocking
	case fchan("eee", nil) <- *fptr("fff"):  // blocking
	case fchan("ggg", nil) <- *fptr("hhh"):  // blocking
	}
}
</code></pre>

The output of the above program:
<pre class="output"><code>bbb
ddd
eee
fff
ggg
hhh
ccc
</code></pre>

<p>
Note that the expression <code>*fptr("ccc")</code> is the last evaluated expression in the above example.
It is evaluated after its corresponding receive operation <code>&lt;-fchan("ddd", c)</code> is selected.
</p>

</div>


